home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940167.txt < prev    next >
Internet Message Format  |  1994-11-13  |  3KB
  1. Date: Mon,  8 Aug 94 04:30:03 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #167
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Mon,  8 Aug 94       Volume 94 : Issue  167
  11.  
  12. Today's Topics:
  13.                            SMTP LZW oddity
  14.  
  15. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  16. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  17. Problems you can't solve otherwise to brian@ucsd.edu.
  18.  
  19. Archives of past issues of the TCP-Group Digest are available
  20. (by FTP only) from UCSD.Edu in directory "mailarchives".
  21.  
  22. We trust that readers are intelligent enough to realize that all text
  23. herein consists of personal comments and does not represent the official
  24. policies or positions of any party.  Your mileage may vary.  So there.
  25. ----------------------------------------------------------------------
  26.  
  27. Date: Mon, 8 Aug 94 09:46:48 +0100
  28. From: A.D.S.Benham@bnr.co.uk
  29. Subject: SMTP LZW oddity
  30. To: TCP-Group@UCSD.Edu, nos-bbs@hydra.carleton.ca
  31.  
  32. In all the code I've seen (apart from my own modified versions),
  33. the SMTP LZW exchange goes like this:
  34.  
  35. Client sends   "XLZW <x> <y>"
  36.  
  37. Server checks that it can do LZW with these parameters, if so it
  38. replies with   "25n XLZW <m> <n> OK" and goes to compressed mode.
  39.  
  40. The client checks the response, and iff (m = x) and (n = y) then
  41. it too goes to compressed mode.
  42.  
  43.  
  44. My question is: why does the client check <m> and <n> ? It's too
  45. late for the client to decide to not go to compressed mode - the
  46. server has already gone compressed.
  47.  
  48. The server code looks as though, in theory, it could return different
  49. values from those the client supplied.
  50. There may not necessarily be a problem in practice, but from a
  51. protocol point of view the exchange seems wrong.
  52.  
  53.  
  54. Andrew Benham
  55. --------------------------------------------------------------------
  56. adsb@bnr.co.uk   BNR Europe Ltd, 140 Greenway, Harlow Business Park,
  57.                                  Harlow, Essex CM19 5QD
  58.                  +44 279 402372    Fax: +44 279 402029
  59. Home:            g8fsl@g8fsl.ampr.org [44.131.181.17]
  60. --------------------------------------------------------------------
  61.  
  62. ------------------------------
  63.  
  64. Date: Sun, 7 Aug 1994 23:42:15 -0700
  65. From: freemanr@dstos3.dsto.gov.au (Roy Freeman)
  66. To: TCP-Group@UCSD.EDU
  67.  
  68. I need to configure ka9q as a DNS.  The version that I have does not appear 
  69. to support DNS.  Therefore which copy of ka9q or other variety of
  70. nos do I require to produce a DNS
  71.  
  72. ------------------------------
  73.  
  74. End of TCP-Group Digest V94 #167
  75. ******************************
  76.